Access control involves authorizing users, groups, and computers to access resources on a network or computer. Resources may include, for example, servers, files, printers, or other peripheral devices. Before a user, group, computer, or other requestor can gain access to a resource, the requestor must identify itself to the security subsystem for the operating system. This identity is contained within an access token that is re-created every time a subject logs on. Before allowing the subject to access a resource, the system checks to determine whether the access token for the subject is authorized to access the object and complete the desired task. The system does this by comparing information in the access token with access control entries contained in an access control list for the resource.
Access control entries can allow or deny a number of different behaviors, depending on the type of object. For example, available options on a file object can include “Read”, “Write” and “Execute”. On a printer, available access control entries can include “Print”, “Manage printers”, and “Manage documents”. These access control entries define permission that relate to the scope of access granted to a user or group for a resource. For example, a finance group can be granted Read and Write permissions for a file named Payroll.dat. Using an access control user interface, an authorized administrator can set permissions for resources. Permissions can be granted to any user, group, or computer. Common permissions for different types of resources include “read”, “modify”, “change owner”, and “delete”.
Upon receiving an access request, the system identifies the user and checks the access control list for the resource for access control entries that apply to the requestor (the user and the groups to which the user belongs). For identification purposes, the system may utilize the Security Account Manager (SAM), which is a database file that stores user passwords in Windows® based systems. SAM can be used to authenticate local and remote users. If the system comes to the end of the access control list and the desired access is still not explicitly allowed or denied, the system denies access to the requested resource.
Windows® Servers platforms rely on a distributed authorization model, with each operating system instance providing its own authorization and authentication services. While the use of local authentication on Windows® Servers may be restricted under IT risk policies, multiple exceptions exist due to technological or operational constraints. Additionally, in the event that the operating system is unable to associate with the domain and perform domain-based authentication, a local authentication mechanism enables fall-back for recovery and trouble-shooting purposes.
Local authorization is the only solution capable of providing flexible access controls in a large scale environment. However, a challenge with the local authorization model is the lack of a scalable administrative solution.
In a typical Windows® Server environment, access is granted by permanently adding an account or a directory based group into a privileged group, e.g. “administrators”, for a local server to the access control list. The only offering is based on group policies, and supports policy level lock-ins with no effective exception handling. To support sufficient granularity, a policy-based solution would require creation of thousands of unique policy objects and would still result in a significant percentage of exceptions, effectively exempting those systems from the management structure.
Thus, in the policy based system, standing access with a high level of control is granted for these members of the privileged group on a continuous basis. Even when the directory-based model is used in combination with password vault solutions, such as Enterprise Password Vault (EPV), it grants each administrative account a scope of authority that is significantly higher than needed. Typically, one account or group is provisioned with rights for as many as thousands of Windows® Server systems. This method lacks flexibility and produces a model in which a group or multiple groups receive uniform and generally excessive access to the entire server population.
Alternatively, server systems may utilize a granular application of specific rights to each individual server in a system. This method is extremely labor intensive, spawns multiple inconsistencies, and leads to the creation of duplicative and unnecessary domain security groups. Additionally, unauthorized changes and the granting of requests for emergency access can create risks.
Furthermore, continuous monitoring of access rights is challenging, as implementing changes made locally on each Windows® server typically requires costly security monitoring software having heavy dependencies on hardware infrastructure. Various methods of managing on-demand access have been attempted. However, no known methods have been successful in providing on-demand access to server resources in systems having very large numbers of server systems and disjointed networking tiers.
Currently, no capability exists to lock down local SAM and local privileges from modification. In fact, such modifications can be made not only interactively, but also programmatically, for example, during software installations. Accordingly, in the absence of this capability, a solution is needed that will focus on providing periodic reconciliation of specific SAM properties and privileges, reporting changes in near real time, and providing the capability for updating local SAM and local privileges on demand.
Accordingly, a solution is needed that is scalable and secure and does not grant excessively high privileges across multiple servers when access is needed only for a limited number of servers. Furthermore, a solution is needed that modifies user rights in near real time to facilitate on-demand access changes to access controls.